Local IP access (LIPA) provides access for IP capable user equipments (UE) connected via a Home Node B/Home eNode B (HNB/HeNB) to other IP capable entities in the same residential/enterprise IP network. With LIPA in place, an UE using LIPA can be contactable by another IP endpoint in the same residential/enterprise IP network via LIPA. Traffic for LIPA is expected not to traverse the mobile operator's network except HNB/HeNB. In this manner, resources in the mobile operator's network could be less congested and better utilized.
The 3rd-Generation Partnership Project (3GPP) defines TR 23.829 presenting several possible solutions to achieve LIPA. The L-Gateway (L-GW) based solution (solution 1, variant 1) will be very likely selected as the basis for normative specification of LIPA in 3GPP. In L-GW based solution, a local public data network (PDN) gateway is deployed in the Local Network having a connection to the mobile operator's core network. The L-GW may be collocated with a HNB/HeNB or standalone. In this technology, traffic going through the operator's core network and traffic for LIPA access use separate PDN connections. In this manner, LIPA PDN can be identified by a well-defined access point name (APN) or a specific indication independent of the APN. In terms of mobility support, the L-GW based solution where the L-GW function is collocated with the HNB/HeNB can support mobility of UEs in connected mode to another HNB/HeNB from the same local network with some limitations. The L-GW based solution where the L-GW function is standalone is expected to not have those limitations; details however are at this time for further study. Hence, the latter solution is ideally suited for enterprise deployments. However, both solutions will require some modification in the operator's core network, an L-GW needs to be deployed in the Local Network and two IP addresses will be used.
An alternative implementation of LIPA is the network address translation (NAT) based solution, also proposed and described in 3GPP TR 23.829. While the NAT-based solution (solution 2) will be very likely not selected as the normative specification, it will probably be included in the non-normative section of future standard as an alternative implementation proposal. With NAT, IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. The NAT-based solution requires packet inspection, NAT and traffic mapping functionalities in HeNB.
Even though NAT-based solution will be very likely not included in the normative specification, the following identified features to make the NAT-based solution an attractive alternative: first, NAT-based is very likely to be more cost-effective than the L-GW based solution; second, NAT-based solution requires less modifications in the operator's core network and has less impact on the operator core network; third, only one IP address is used; and fourth, NAT-based solution is applicable to all UEs, including single PDN capability UEs. However, the mobility cannot be supported easily for the NAT-based solution. Hence, the NAT-based solution is mostly attractive to applications where cost effectiveness, instead of mobility, is the first priority concern, such as, residential deployments.
One U.S. Patent document disclosed a local IP access scheme, wherein different interfaces are used for accessing different services in some implementation, an access point (e.g., Femto node) proxy provides a proxy function, such as a proxy address resolution protocol (ARP) function, for an access terminal in some implementation, an access point proxy provides an agent function, such as a Dynamic Host Configuration Protocol (DHCP) function, in some implementation, and an access point may determine whether to send a packet from an access terminal via a protocol tunnel based on the destination of the packet in some aspects. In addition, NAT operations may be performed at an access point to enable the access terminal to access local service, where one IP interface and one public IP address is assigned to the access terminal. The disclosed prior art also claims that a NAT comprising substituting a network IP source address assigned to the access terminal for an operator network with a local IP source address assigned to the access terminal for the Local Network.
On the other hand, an application layer gateway (ALG) is an application specific translation agent that allows an application on a host in one address realm to connect to a counterpart running on a host in different realm transparently. To support address and port translation for certain application layer protocols, such as, Session Initiation Protocol (SIP), ALG conducts deep packet-inspection of all packets. An ALG understands the protocol used by the specific applications that the ALG supports.
Additional related concepts in mobile communication technology are given below to lay ground for later discussion. For example, SIP is a signaling protocol used for establishing sessions in an IP network. A session could be a simple two-way telephone call or a collaborative multimedia conference session. SIP is based on the request-response paradigm. SIP defines the following methods—INVITE, ACK, BYE, CANCEL, OPTIONS, REGISTER, and INFO. Various SIP responses can be defined, for instance, 1xx response category is informational, 2xx response category implies successful, 3xx response category is for redirection, 4xx response category is for request failure, 5xx response category is for server failure, and 6xx response category is for global failure.
The IP multimedia subsystem (IMS) is an architecture framework for delivering IP multimedia services. It was originally defined by the wireless standard body 3GPP, as a part of the vision for evolving mobile networks beyond GSM.
With respect to SIP and ALG, the aforementioned U.S. Patent document does not consider SIP and SIG ALG to facilitate LIPA implementation. FIG. 1 shows an exemplary schematic view of the system described in the aforementioned U.S. patent document extended by a SIP Server to enable the establishment of a SIP session within the local network. FIG. 1 also shows schematically the SIP signaling and RTP/RTCP paths. FIG. 2 shows an exemplary schematic view of the SIP messages signaling flow used in SIP signaling process and the RTP/RTCP traffics. As shown in FIG. 2, an INVITE message from UE A is relayed by SIP server to UE B, and an OK message from UE B is also relayed by SIP server to UE A. After an ACK (acknowledgement) is sent from UEA to UE B, the SIP signaling process is complete.
FIG. 3 shows a schematic view of details of the NAT for an exemplary embodiment of FIG. 1. As shown in FIG. 3, the exemplary NAT substitutes a source IP address assigned by an operator in an IP packet with a source IP address assigned by the Local Network in case of LIPA.